Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustc_span: Generate keyword classification functions automatically #75309

Closed
wants to merge 2 commits into from

Conversation

petrochenkov
Copy link
Contributor

The generated functions are compatible with symbols not forming continuous ranges.
This is a nicer alternative to 4896614 from #74554.
r? @nnethercote

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 8, 2020
@petrochenkov
Copy link
Contributor Author

@bors try @rust-timer queue

The classification functions are array searches rather than simpler range checks, so they are supposed to be slower.
However, parsing is fast in general, so this shouldn't have a noticeable effect?

For small lengths (like those of the keyword lists) linear search is preferable to binary search.
For optimal speed the arrays should be sorted (to please branch predictor), but this would require copypasting some logic from rustc_span to rustc_macros after #74554 is merged.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Aug 8, 2020

⌛ Trying commit 260234aa5f640d8f080e84a58d9292900b3f7348 with merge 2e0259109d9ebdf5660e31aa7bce983d3108f27c...

@petrochenkov petrochenkov mentioned this pull request Aug 8, 2020
if let Some(class) = class {
keyword_class_stream.extend(quote! {
fn #class(self) -> bool {
[#class_stream].contains(&self)
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum Aug 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does seem a bit unfortunate to lose the O(1) range-checking here, but I guess this is probably not too hot.

Maybe LLVM takes care of things for us, too, though I somewhat doubt it.

Edit: Oh, I see your comment now. We can wait on perf.

I was expecting that we'd lower to #class_stream[0] <= self && self <= #class_stream.last, though obviously that syntax isn't actually a thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is supposed to land only together with #74554, which also regresses performance due to inability to do range checks, but improves it more due to inlining.

@bors
Copy link
Contributor

bors commented Aug 8, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: 2e0259109d9ebdf5660e31aa7bce983d3108f27c (2e0259109d9ebdf5660e31aa7bce983d3108f27c)

@rust-timer
Copy link
Collaborator

Queued 2e0259109d9ebdf5660e31aa7bce983d3108f27c with parent 1facd4a, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (2e0259109d9ebdf5660e31aa7bce983d3108f27c): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

@Mark-Simulacrum
Copy link
Member

Seems like a definite slow down, but mostly only affecting doc builds (1-2% on smaller crates). <1% regression in instruction counts on non-doc builds.

@nnethercote
Copy link
Contributor

Yeah, maybe we shouldn't land this until we are certain about #74554?

let mut current_class = None;
while !input.is_empty() {
if input.peek(Token![fn]) {
input.parse::<TokenTree>()?;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if there's any simpler way to skip a token with syn parser.

@petrochenkov
Copy link
Contributor Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Aug 9, 2020

⌛ Trying commit 1003529c05c7e35faea2e246758d77b7151853ce with merge a69ffd7a844a5bb0dea3220cceeb958ab7a2d3ad...

@petrochenkov petrochenkov added S-waiting-on-perf Status: Waiting on a perf run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 9, 2020
@bors
Copy link
Contributor

bors commented Aug 9, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: a69ffd7a844a5bb0dea3220cceeb958ab7a2d3ad (a69ffd7a844a5bb0dea3220cceeb958ab7a2d3ad)

@rust-timer
Copy link
Collaborator

Queued a69ffd7a844a5bb0dea3220cceeb958ab7a2d3ad with parent f50f1c8, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (a69ffd7a844a5bb0dea3220cceeb958ab7a2d3ad): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

@petrochenkov
Copy link
Contributor Author

petrochenkov commented Aug 9, 2020

Ok, match looks better than contains (but is still a regression).

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Aug 9, 2020
@@ -26,12 +26,14 @@ symbols! {
Keywords {
// Special reserved identifiers used internally for elided lifetimes,
// unnamed method parameters, crate root module, error recovery etc.
fn is_special:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This confuses code highlighting in my editor (vscode + rust-analyzer), but fn is required for searchability.
Perhaps the list needs to go into braces, e.g. like this:

fn is_special {
    Invalid:            "",
    PathRoot:           "{{root}}",
    DollarCrate:        "$crate",
    Underscore:         "_",
}

@petrochenkov petrochenkov removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 11, 2020
@petrochenkov petrochenkov added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 11, 2020
@petrochenkov
Copy link
Contributor Author

error[E0107]: wrong number of type arguments: expected 3, found 2
  --> src/librustc_macros/src/symbols.rs:50:17
   |
50 | struct Keywords(IndexMap<Option<Ident>, Vec<Keyword>>);
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 3 type arguments

Excuse me?
Somehow rustc_macros gets built without has_std feature being enabled for the indexmap crate.

@Mark-Simulacrum
Copy link
Member

Hm so indexmap is using autocfg to probe for std's presence, I think via this bit of code. My guess is that's not using the right rustc or not passing it the right parameters, but I'm not sure without seeing the actual build log from autocfg we'd be able to say much.

The check in rustdoc using it is artificial and not helpful
@petrochenkov
Copy link
Contributor Author

I couldn't reproduce the indexmap error locally, but fixed it by providing the hasher argument explicitly.

@shepmaster
Copy link
Member

My guess is that's not using the right rustc or not passing it the right parameters

See also rust-lang/cargo#8646

@petrochenkov
Copy link
Contributor Author

So, this PR should probably just be cherry-picked into #74554 since it's not valuable by itself.

@bors
Copy link
Contributor

bors commented Aug 30, 2020

☔ The latest upstream changes (presumably #74862) made this pull request unmergeable. Please resolve the merge conflicts.

@petrochenkov
Copy link
Contributor Author

Closing since #74554 has been closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants